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CARD, DEVICE, PRODUCT AND PRODUCT MANAGEMENT SYSTEM 



The present invention relates to a system for managing 
products associated with cards and devices, for example, 
5 payment, loyalty, identification, access, insurance, 
information and transportation products. 

By "card" we mean, broadly, any apparatus that can be 
used to facilitate product transactions (typically with a 
card-accepting device) . This includes magnetic-striped 
10 cards, smart cards, "virtual" cards ("wallets"), memory 
cards, microprocessor cards, contactless cards, optical 
cards, laser cards, embossed cards, tickets, boarding 
passes, coupons, and printed cards. It also includes any 
apparatus which might not be a card but which may provide 
15 for similar functionality. 

By "device" we mean, broadly, any apparatus that can 
be used to facilitate product transactions (typically with 
a card). This includes ATM' s, EFTPOS terminals, draft 
capture terminals, card accepters, contactless card 
20 readers, optical readers, laser readers, ticket readers, 
boarding pass readers, coupon readers, imprinters, and 
"virtual" devices (eg for reading "wallets"). 

The use of apparatus such as cards and/or devices for 
facilitating product transactions is ubiquitous. Note that 
25 by the term "product" we mean the application that the card 
and/or device associated with the product is arranged to 
facilitate. There are a large number of such products and 
a potential for many more. They include (but are not 
limited to) : 

30 1. Payment products - e.g. credit, charge, debit, 

stored value, purchasing, payphone, calling, and account 
billing products. 

2. Loyalty products - e.g., airline frequent flier, 
product coupon, retailer discount and customer frequency 

35 products. 
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3. Identification products - e.g., license, ID, 
passport and electronic signature products. 

4. Access products - e.g., building, computer, 
mobile phone, device and security access products. 

5 5. Insurance products - e.g., health, motor vehicle 

and general insurance products. 

6. Information products - e.g., medical, health, 
personal, computer, motor vehicle service and portable 
information file products. 
10 7. Transport ticketing products - e.g., airline 

ticket and boarding pass, rapid transit ticketing, car 
park, parking meter and toll road transport products. 

These products are often but not exclusively card 
based. 

15 The management of card- and/or device-related 

products, as well as the associated message data, is 
complex. Any product usually requires the involvement of a 
number of different participants. In a credit card 
product, for example, the participants involved will 

20 usually include the following: 

1. Card Issuer. This may be an entity such as a 
bank that issues and/or subsequently manages a card 
for facilitating the credit product, to a cardholder. 
Note that the card issuer may outsource certain 

25 functions to third parties (e.g., card manufacturing 

to a card-manufacturing bureau, to specifications 
provided by the card issuer) ; 

2. Cardholder. This is usually the person holding 
the card. Note that the cardholder may be an 

30 inanimate object such as a motor vehicle, or a 

corporation who assigns the card to a position or 
function. 

3. Transaction Acquirer. This may be an entity such 
as a bank that typically (but not exclusively) 

35 installs and/or subsequently manages a device that 

accepts cards to facilitate a credit product 
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transaction, to a card accepter. The transaction 
acquirer is typically responsible for the management 
of transactions initiating from these devices (e.g., 
the routing of product transactions received from and 
5 sent to the devices, the routing of product 

transactions to processors to facilitate the approval 
and/or processing of product transactions) . The 
transaction acquirer may in some cases be the same 
entity as the card issuer (e.g., where the same bank 
10 that issues the card acquires the product 

transaction) . Note that the transaction acquirer may 
outsource certain functions to third parties (e.g., 
product transaction switching to a transaction- 
switching bureau, to specifications provided by the 
15 transaction acquirer) . 

4. Card Accepter. This is usually the participant 
accepting the card and presenting the product 
transaction to the transaction acquirer via the 
device. The card accepter in the case of a credit 
20 card may be a retail merchant. 

In addition to the above, particularly in the case of 

credit cards, a " scheme operator" participant may also be 

involved. Product transactions may be routed via a scheme 

operator from the device or transaction acquirer to the 
25 card issuer for approval and/or processing of the product 

transaction. Examples of scheme operators include VISA® 

and MASTERCARD®. 

The transaction acquirer may need to authorise the 

product transaction with the card issuer, before the 
30 transaction is approved. Authorisation for the transaction 

may be sought on-line directly from the card issuer, via a 

scheme operator (where a scheme is involved) or a third 

party ( XN stand in" ) . 

The transaction acquirer will need to clear and settle 
35 the product transaction with the card issuer, as well as 

provide the product transaction to the card issuer so it 
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can be processed. In credit card transactions, this can be 
done in a number of ways. Where the transaction acquirer 
and the card issuer are the same participant, it can be 
settled and provided for processing directly with the card 
5 issuer (an "on us" product transaction) . Where the 
transaction acquirer and the card issuer are different 
participants, it can be settled and provided for processing 
through a bilateral interchange agreement or via a scheme 
operator (where a scheme is involved) interchange 

10 arrangement ("off us"). 

In a credit card system, the card accepter usually 
pays a fee to the transaction acquirer, who in turn usually 
pays a fee to the card issuer (as well as the scheme 
operator or third party, if applicable) . In some cases, 

15 the cardholder will also pay a fee to the card issuer 
and/or card accepter. Alternately, the flow of fees 
between the various participants may be reversed in some 
cases. 

Other types of products than credit cards may include 
20 variations on the above, but they will be substantially 
similar. For loyalty programs, for example, a bureau may 
be involved for the calculation of loyalty points. 

Management of such products and the relationships 
between the participants involved is complex. Any 
25 management system (s) must be able to carry out a large 
number of processes and manage information enabling the 
management of the product and relationships. For example, 
the management system (s) must be able to: 

1. make decisions and conduct processes based on 
30 product transaction content; 

2. route product transactions to and from devices 
and other participants; 

3. obtain and maintain information on card holders, 
card accepters and other participants; 

35 4. support cryptographic processing (messages may be 

encrypted) . 
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The implementation of any product may necessarily 
involve negotiations between various entities involved to 
decide on the product operating parameters and data that 
will be required. A management system (s) will then be 
5 designed to operate the product, including devices and 
processing systems for processing the necessary product 
transactions and other data. Such dedicated systems do not 
easily lend themselves to alteration or adaptation to 
facilitate operation of additional or other products. 

10 For example, a product scheme and product package may 

overlap, such as where a VISA® or MASTERCARD® credit 
product issued by one bank is tied to a package of products 
in a confined locality (e.g., the Qantas/Telstra/Visa 
scheme in Australia or the American Express/American 

15 Airlines/Hilton Hotels scheme in North America) . 

Present card and/or device product management systems 
therefore have a number of problems. Firstly, as discussed 
above, they are not readily adaptable to support 
significant changes in the product. 

20 Secondly, if a card or device is lost or damaged and 

requires replacement, it can be a complex matter to obtain 
all the necessary information to reissue the card or re- 
establish the device. This is particularly the case where 
a card and/or device may be associated with more than one 

25 product (e.g., a credit card product and a loyalty scheme 
product supported by the same card and/or device) . 
Information may have to be obtained from a number of 
different entities in order to reissue the card and/or re- 
establish the device. 

30 The presently available management systems limit the 

extent by which cards associated with different products 
can be implemented (multi-product cards) . Likewise, the 
presently available management systems also limit the 
extent to which devices supporting different products can 

35 be established (multi-product devices) . The more products 
that there are associated with a card and/or device, the 



PCT/AU00/00123 

WO 00/51070 - 6 - 

more negotiation is required between the different 
participants and the more complex the management system (s) 
required. One of the major benefits of smart cards which 
is often touted is their ability to support many different 

5 products on a single card. A cardholder may therefore only 
need to carry one or two cards that support all the 
products that they may require. The present management 
systems stand in the way of the implementation of multi 
product cards, as well as multi-product devices. 

10 The present management systems often result in product 

operating errors and delays in completing transactions, 
particularly where the product is one of a multiple-product 
system. The present multiple-product systems generally 
arise by the addition of a further product to an already 

15 existing card/device based product. The management system 
is amended or added to to cope with the further product. 
For example, where the further product includes a loyalty 
scheme, presently transaction information from the primary 
product, (e.g. credit card product) will undergo further 

20 processing to establish data associated with the loyalty 
product. Primary participants in this system are the 
managers of the credit card product (e.g. transaction 
acquirer and card issuer for the credit card product) . To 
enable the loyalty product the primary participants provide 

25 further separate processing. For example, the transaction 
acquirer and the card issuer may be a bank. The bank is 
responsible for processing a transaction it receives from 
devices associated with the credit card product. As well 
as transactions associated with the credit card product, in 

30 a separate process (usually carried out in batch) the bank 
must determine which of the credit product transactions are 
associated with card holders who belong to the loyalty 
scheme. The data from those transactions is then used to 
calculate loyalty points. Loyalty points are often 

35 calculated by a separate bureau which receives the relevant 
transaction data from the bank. The loyalty points may 
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then be passed on to the loyalty product manager. The 
transaction data- processed by the transaction acquirer will 
include the same data whether the transaction is associated 
with the loyalty scheme or not. The transaction acquirer 

5 (or other entity processing the transactions) must first of 
all "match up" the transaction data with the loyalty scheme 
(which may be by identifying the card holder the 
transaction is associated with determining whether or not 
that card holder is a member of the loyalty scheme) and 

10 then pass only the relevant transactions onto the loyalty 
product manager (or bureau) . In the present systems 
therefore, the transaction must go past the transaction 
acquirer first for primary processing before it is passed 
on for further processing to enable implementation of the 

15 loyalty product. This complicates processing. 

This system can result in errors and delays. For 
example, it may take weeks or even months for loyalty 
points to be credited to a card holders account. In some 
cases, loyalty points may not be allocated at all. 

20 Further, redemption of loyalty points is done as a 

totally separate process, which is also slow and requires 
effort by the card holder. 

In such a system there is no real control of the 
loyalty product by the loyalty product manager. Further, 

25 there is no product as such on the card or device. The 

card and device system have been constructed to support the 
primary product (e.g. the credit card product) and 
operation of the further product is done "behind the 
scenes" . There is no information in the transaction for 

30 the loyalty product manager. Separate "batch processing" 
must be provided by the transaction acquirer. 

The present "card processing environment" can be 
considered either a single role environment (where all 
product transactions are "on us") or a dual role 

35 environment (where at least some product transactions are 
"off us"). In the case of a single role environment, the 
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card issuer is also the transaction acquirer. In the case 
of a dual role environment, the card issuer and transaction 
acquirer may be separate. It should be noted that there 
might be multiple participants carrying out a particular 
5 role (i.e., multiple card issuers and multiple transaction 
acquirers within a dual role environment) . 

Where a further product is involved being managed by a 
separate product manager participant, such as described 
above, the product manager is an indirect participant. 
10 Indirect participants rely on the participants in the 

single role or dual role environment to provide them with 
the information necessary for them to manage the product. 
They are not directly involved in the "card processing 
environment" . The raw data provided in the transaction is 
15 not usable by the further indirect participant. Further 
processing must be provided by a separate process. 

The present applicants have identified the possibility 
of a further role being involved in the card processing 
environment to facilitate the management of card device- 
20 based products, particularly where multiple products are to 
be supported by cards and/or devices. The applicants have 
termed this third role a "product owner". The product 
owner is an entity who can be considered to "own" a product 
associated with the card and/or device. The product owner 
25 may be responsible for the management of the product in 
isolation of other card and/or device management 
requirements (i.e., they may not be responsible for the 
issuing or management of cards, nor the establishment or 
management of devices) . As some of the previous functions 
30 of the card issuer may be transferred to the product owner, 
the applicants have re-named the previous card issuer role 
as "card manager". Likewise, as some of the previous 
functions of the transaction acquirer may be transferred to 
the product owner, the applicants have re-named the 
35 previous transaction acquirer role as "device manager". 
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Note that a product may be implemented as a product 
application on a card, on a device, or distributed on both 
card and the device. Smart cards in particular facilitate 
the provision of product applications on the card. The 

5 management system of the present invention, however, 
although particularly appropriate for the smart card 
environment may also be implemented to manage products 
which may not be on the card, which may be on the device, 
or which may be neither on the card or on the device. 

10 The present invention provides a card device and 

product management system, including a card management 
means which enables a card manager participant to perform a 
card management role alone, without managing products 
associated with a card and without managing devices; 

15 a device management means which enables a device 

manager participant to perform a device management role 
alone, without managing products associated with the card 
and without managing cards; and 

a product management means, which enables a product 

20 owner participant to perform a product management role 

alone, without managing cards and without managing devices, 
whereby all three roles can be performed by separate 
entities . 

The terms "card", "device" and "product" have the 
25 definitions which are given above, as amplified as follows: 
The "card" includes any means which enables representation 
of a relationship between a card holder and a card manager. 
In the simplest terms, it may include merely an 
identification number or account number. It is a guarantee 
30 that the card holder is enabled to carry out the product 
transaction. It may include a token or electronic wallet 
which is utilisable over a computer network such as the 
Internet, from a card holder's PC. 

Similarly, a "device" is anything capable of 
35 representing a relationship between a device manager 

(transaction acquirer) and a card acceptor (merchant) . It 
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may be a "virtual" device accessible via a Web page on the 
Internet, for example. 

The addition of a product owner role to the single or 
dual environment, preferably creates a "tripartite 
5 environment" , where there may be three roles required to 
facilitate the management of card and/or device-associated 
products : 

1. the management of cards being carried out by the 
card manager. 

10 2. The management of devices, being carried out by 

the device manager. 

3. The management of a product being carried out by 
the product owner. 

Note that all these roles may in some circumstances be 

15 carried out by the same participant, i.e. operating each of 
the device management means, product management means and 
card management means. 

Each of the product management means, card management 
means and device management means preferably includes a 

20 software module controlling a processing means to 

facilitate the product owner, card manager and device 
manager roles. 

The system preferably further comprises a message 
management means which is arranged to manage the routing of 

25 message data between cards, devices and the card, device 
and product management system. In a preferred embodiment, 
the message management means includes a software module 
which can control a processing means to control the routing 
of message data. Note that by message data is meant any 

30 data including transaction data, that needs to be routed 
within the system. Preferably, each participant in the 
system is provided with a message management module. For 
example, where the card manager, product owner and device 
manager are separate entities, each of the entities will 

35 have a message management means to control the routing of 
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message data within the system, i.e. between the management 
means and the cards and devices. 

Preferably, the device management means include 
storage means for storing product owner identification 

5 data, identifying product owner participants responsible 
for managing products associated with devices managed by 
the device manager participant, and card acceptor 
identification data, identifying card acceptors using 
devices managed by the device manager participant. 

10 Preferably, the product management means includes 

storage means arranged to store card manager identification 
data identifying card managers managing cards supporting 
products managed by the product owner participant. 

The product management means may also store card 

15 holder identification data, identifying card holders 

holding cards having products managed by the product owner 
participant, and card acceptor identification data, 
identifying card acceptors having devices supporting 
products managed by the product owner participant. 

20 Preferably, the card management means is arranged to 

store product owner identification data identifying product 
owner participants responsible for managing products 
associated with cards managed by the card manager 
participant. The card management means may also store card 

25 holder identification data, identifying card holders 
holding cards managed by the card managed participant. 

Preferably, each of the management means also stores 
links to the management means of other participants. 

In each management means, a database may store the 

30 required data. 

Note that in each case identification data may not be 
the actual identity of the entity. For example, the 
product owner may not need necessarily to have the name of 
the card holder who has a product of the product owner. It 

35 may be sufficient to have an ID number, without knowing the 
actual name of the card holder. It may only be necessary 
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for the card manager to know the actual identity of the 
card holder. In many cases a card holder will not wish to 
provide their identity to more entities than necessary. 
The present system enables products to be provided to a 
5 card holder without the card holder having necessarily to 
provide his identity to a product owner. 

Usually, it will be required that the card managers 
have an actual identity of the card holder and that the 
device managers have an actual identity of the card 
10 acceptor. Other than this, actual identities do not 

necessarily need to be provided to any other participant. 

Any product owner must have a relationship with a 
cardholder. The relationship with the cardholder need not 
be direct. It could be by way of a card manager. What the 
15 product owner requires in the relationship with the 

cardholder is the right type of product data to enable 
management of the product. This can be any data that the 
product owner requires from the cardholder, as well as any 
data that the product owner provides to the cardholder. It 
20 may be a product transaction, the name and address of the 
cardholder, a card application for a product, a unique 
identifier of the card (e.g., a card number) and 
cardholder, or any other information. 

Any product owner must have a relationship with a card 
25 accepter. The relationship with the card acceptor need not 
be direct. It could be by way of a device manager. What 
the product owner requires in the relationship with the 
card accepter is the right type of product data to enable 
management of the product. This can be any data that the 
30 product owner requires from the card accepter, as well as 
any data that the product owner provides to the card 
accepter. It may be a product transaction, the name and 
address of the card accepter, a device application for a 
product, a unique identifier of the device (e.g., a device 
35 number) and card accepter, or any other information. 
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The relationship with the card accepter and the 
cardholder may be implemented dynamically. That is, the 
relationship may occur only when the card accepter and 
cardholder come to operate the product e.g., the product 
5 may be loaded by the card acceptor and cardholder at any 
time . 

To manage the cardholder (referred to by the product 
owner as the "product-holder" ) relationship, data such as 
the identity of the cardholder will usually be required by 

10 the product owner. The identity need not be an actual 
identity but may merely be an identification number. In 
some cases even identity information may not be necessary 
i.e., it may be enough for the product owner to receive 
transaction data indicating that there is a card holder. 

15 Again, the relationship with the cardholder may be indirect 
and any information on the cardholder could be provided by 
other parties in the system e.g., a card manager. 

To manage the card accepter (referred to by the 
product owner as the "product accepter") relationship, data 

20 such as the identity of the card accepter will usually be 
required by the product owner. The identity need not be an 
actual identity but may merely be an identification number. 
In some cases even identity information may not be 
necessary i.e., it may sufficient merely to receive 

25 transaction information from the card acceptor so that the 
product owner is aware that there is a card acceptor. 
Again, the relationship with the card accepter may be 
indirect and any information on the card accepter could be 
provided by other parties in the system e.g., a device 

30 manager. 

Separation out of product management from other 
aspects of card management provides a number of advantages. 
Any card and/or device product can be managed separately 
from all other aspects of the card- and/or device-related 
35 environment. Thus, the role of the product owner is 

simplified (management of the product only), such that the 
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product owner - need not be concerned with, for example, 
the provision and management of cards and - devices 
required to support their product. This also results in 
less effort on the part of card managers and device 
5 managers to support the products of a product owner. For 
example, a chain of restaurants may wish to manage a 
loyalty scheme, where they would be the product owner of 
the loyalty scheme. Their product management system would 
only need to be able to manage the information required to 

10 manage the loyalty scheme, not the broader aspects of card 
and/or device management unrelated to their loyalty scheme. 
These other aspects of card and device management will be 
conducted by card manager and device managers that agree to 
support the restaurant chain's product. 

15 Preferably, the card management means manages aspects 

of the card-related environment that are associated with 
the card manager. The card manager management system (s) 
should preferably be able to uniquely identify each card it 
manages, maintain data relating to that card, and share 

20 such data with product owners and device managers. 

Preferably the device management means manages aspects 
of the device-related environment that are associated with 
the device manager. The device manager management 
system(s) should preferably be able to uniquely identify 

25 each device it manages, maintain data relating to that 
device, and share such data with product owners and card 
managers . 

With the management system(s) of the present 
invention, therefore, an entity that wishes to be involved 

30 in any one aspect of the tripartite card environment 
conceived by the applicant (product management, card 
management and device management) will require only the 
appropriate part of the system which relates to management 
of the aspect of the environment that they are responsible 

35 for, together with the message management means, enabling 
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communications between the management systems of different 
entities in a tripartite environment. 

The product owner,- for example, thus manages the 
product in isolation from all the other tasks. Aspects of 
5 the product may be updated (e.g., a new version of the 
product application on the card) through the product 
management means in a tripartite environment, thus avoiding 
the need for that entity to also have a card and/or device 
management means. 

10 This serves to illustrate an important aspect of the 

present invention. In the prior art systems discussed in 
the preamble where a third party operates a product such as 
a loyalty scheme as a secondary product receiving data from 
a system which has been designed to operate a primary 

!5 product, the loyalty product owner is not really a party to 
the management system at all. The prior art environment is 
dual role or single role environment, and the third party 
depends upon the parties to the primary product for any 
information, transactional information and to make any 

20 amendments to the product. Where the product is on the 
card or in the device, it is the primary participants who 
must make amendments to the product application. 

In the present invention, the product owner is 
preferably able to affect control over the product. For 

25 example, where the product application exist either on a 
device or on a card (such as a smart card) or on both, the 
product owner may be able to download an updated 
application via the management system, perhaps without any 
intervention of any of the other management participants in 

30 the system. Transaction data created in relation to the 
product may be routed to the product owner via the message 
management means of the other participants in the system, 
without processing by the management modules of the other 
participants. The management system of the present 

35 invention, therefore, preferably facilitates enabling the 
product holder to communicate directly with the product 
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e.g., to put information on the product or to receive 
information from the product. This cannot be done in the 
prior art by a third party operator who is not directly 
involved in the prior art dual role or single role 
5 environment. 

Further, with a management system in accordance with 
the present invention, the replacement of cards and devices 
that have been lost, stolen, damaged, destroyed, - re- 
assigned or the like becomes much simpler. A card or 

10 device may include a number of products which are known by 
the management system (s) of the card manager and the device 
manager, which also maintains non-product specific data. 
The management system) s) of the card manager and device 
manager may also maintain product specific data provided by 

15 each product owner, or may maintain links to each product 
owner's management system such that this product-specific 
data can be obtained. In this way, a card manager or 
device manager may obtain data from the management 
system(s) of product owners that, together with data 

20 maintained on their own management system, will enable a 
card or device to be reconstructed and replaced. 

The provision and management of multi-product cards 
and devices becomes simpler with a management system in 
accordance with the present invention. If a product owner 

25 wishes to deploy a product onto a card or device, all they 
need do is obtain the product management system and message 
management package, and establish a relationship with a 
card manager and device manager for that product. The card 
manager can then assist the product owner to deploy the 

30 product on their cards, and the device manager can assist 
the product owner to deploy the product on their devices. 
Once the product is operational, the device manager and 
card manager can configure their management systems to 
manage transactions facilitated by the product. For 

35 example, the device manager's management system may route 
product transactions received from their devices directly 
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to the product owner's management system, and the card 
managers' management system may inform the product owners' 
management system of any change of address details advised 
by the cardholder. 
5 The security and privacy aspects of the system of the 

present invention are also particularly advantageous. 
Cardholders are often reluctant to give too many personal 
details to certain entities. With the present invention, 
all that the product management system requires is 

10 sufficient information to be able to manage the product. 
The personal identity of a cardholder may not be required. 
Such aspects can be left to the card manager. If the card 
manager is a reputable bank, therefore, for example, the 
product owner may " trust" the bank to ensure the bona fides 

15 of the cardholder, and thus would not require this 

information themselves. This is advantageous for the 
cardholder as it limits the number of entities that require 
detailed personal information, but still enables the 
cardholder to obtain access to multiple products, thus 

20 protecting personal privacy. If the product owner must 
communicate with the cardholder, this can be achieved 
through the card manager who can link the unique identifier 
of the cardholder maintained by the product owner with the 
personal information of the product owner, and then 

25 communicate directly with the latter. 

Customer service is also facilitated by the system of 
the present invention. The cardholder may need only a 
single contact (usually the card manager) if a product is 
not operating to satisfaction. A cardholder complains to 

30 the card manager who may be able to process the complaint 
themselves or who will be able to pass it on straight away 
to thie product owner (or other relevant party) via the 
management system. The cardholder does not require multiple 
contacts corresponding to each one of the multiple 

35 products. 
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The management system of the present invention also 
preferably includes interface means to interface the 
management system with external systems. This interface 
means is preferably provided in the form of software 
5 modules which the applicant terms "business modules" which 
operate a processing means to interface with a desired 
external system. For example, a product owner may already 
have or may wish to design their own external system for 
processing aspects of a product. A business modale 

10 therefore provides a link between the external system and 
the management system and may convert the data being 
received by the management system into a form which is 
usable by the product owners external system. Modules may 
also interface to legacy systems, so that the management 

15 system of the present invention is able to fit in with 
existing systems. 

The present invention further provides a product 
management system, comprising a product management means 
which enables a product owner participant to perform a 

20 product management role alone, without managing cards and 
without managing devices, wherein the system is arranged to 
facilitate the product owner participant to directly affect 
control of a product associated with a card or device. 
By "facilitate" is meant that the system gives a 

25 mechanism by which data can be communicated directly 

between the product holder and the product associated with 
the card or device. The product may be on the card or on 
the device in the sense that software is resting on the 
card or device relating to the product. The card or device 

30 may be considered in terms of "real estate" e.g. the smart 
card may include a number of storage locations which the 
card manager can "let" to product owners. The card manager 
will provide a "key" to enable the product owner to have 
access to a secure location on the card and the product 

35 owner could in fact provide their own key to prevent 

interference with the product on the card. This cannot be 



WO 00/51070 - 19 - PCT/AU00/00123 

done by present multiple product arrangements, wherein 
primary processing is required by a card manager or device 
manager before a product owner, such as a loyalty points 
owner, can manage the product. 
5 The present invention further provides a card 

management system, including a card management means which 
enables a card manager participant to perform a card 
management role alone, without managing products associated 
with a card and without managing devices. 
10 The present invention further provides a device 

management system, including a device management means 
which enables a device manager participant to perform a 
device management role alone, without managing products 
associated with a card and without managing cards. 

15 The present invention further provides a card, device 

and product management system, including a plurality of 
service processing means, each service processing means 
enabling a participant to the system to carry out at least 
one of card, device and product management, and a message 

20 management means provided to each participant in the system 
and arranged to act as a communications interface routing 
message data between each of the service processing means 
and between cards and devices, to enable a network of 
service processing means and a plurality of participants to 

25 interface to carry out card, device and product management. 
The service processing means preferably include card 
management means, device management means and product 
management means, as discussed above. 

The present invention further provides a card, device 

30 and product management system including a network 

comprising a plurality of nodes, each node comprising a 
service processing means enabling a system participant to 
carry out at least one of card, device and product 
management, and a message management means arranged to act 

35 as a communications interface routing message data between 
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the service processing means of each node and between cards 
and devices. 

The present invention further provides a method of 
managing cards, devices and products, comprising the steps 
5 of defining a tripartite environment for card management, 
the card management tripartite environment comprising; 

a card manager participant responsible for managing 
non-product specific card operations; 

a device manager participant responsible for managing 
10 devices for accepting cards and for carrying out product 
transactions; and 

a product manager participant, responsible for the 
management of product-related aspects of the card 
environment, wherein the device manager participant, card 
15 management participant and product manager participant may 
be separate entities. 

The present invention further provides a method of 
managing products, comprising the steps of defining a 
product manager participant, responsible for the management 
20 of products alone, without managing cards and without 
managing devices, and facilitating the product manager 
participant to directly affect control of a product 
associated with a card or device. 

The present invention further provides a method of 
25 managing cards, comprising the steps of defining a card 

manager participant whose role is to perform management of 
cards alone, without managing products associated with a 
card and without managing devices. 

The present invention further provides a method of 
30 managing devices, comprising the steps of defining a device 
manager participant whose role is to perform management of 
devices alone, without managing products associated with a 
card and without managing cards. 

The present invention further provides a generic 
35 system for the management of cards, devices and products, 
the system including a card management module, a device 
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management module and a product management module, which 
can be used separately and networked with each other to 
enable different entities to carry out card management, 
device management and product management alone, and to 
5 network with other similar systems to facilitate card, 
device and product management . 

Preferably, any entity wishing to become involved 
acquires the necessary module (depending on whether they 
are card manager, device manager or product manager) and 

10 configures it to their requirements. Such a generic system 
particularly designed to facilitate the management of 
cards, devices and products is a novel concept. Any number 
of entities can become involved in a networked system. 

The system of this aspect of the present invention may 

15 include any or all of the features of the aspects discussed 
above . 

The present invention further provides a card, device 
and product arrangement, including a computing system 
having storage locations for receiving a plurality of 

20 product applications, and security means enabling selective 
access to the storage locations for a plurality of product 
owners, whereby the product owners may separately access 
and manage their products stored at the storage locations. 
The storage locations for receiving the product 

25 applications may be mounted on the cards themselves eg 
where the cards are smart cards, or may be mounted on 
devices or shared between cards and devices. The storage 
locations can be considered in terms of u real estate" as 
discussed above, and a card or device manager can "let" the 

30 real estate to product owners so that they can run their 
products using the arrangement. The security means may 
comprise a key, preferably in the form of any token which 
enables the product owner access to the storage location (a 
token may be any identifier, eg PIN) . Security means may 

35 also be provided to prevent the card or device manager from 
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accessing a particular product owner's storage location, 
once it has been "let" to that product owner. 

Note that the storage locations need not be mounted on 
the cards or the devices, but may be located elsewhere in 
5 the computer system, or may be distributed within the 
computer system. 

The card, device and product arrangement of the 
present invention is preferably implemented within a card, 
device and product management system in accordance with the 
10 preceding aspects of the present invention discussed above. 
Indeed, the use of such a system facilitates the product 
owner management of their product application stored at the 
storage location. 

Features and advantages of the present invention will 
15 become apparent from the following description of an 

embodiment thereof, by way of example only, with reference 
to the accompanying drawings, in which: 

Fig. 1 is a schematic diagram of a present card- 
related environment; 
20 Fig. 2 is a schematic diagram of a card-related 

environment facilitated by the card management system of 
the present invention; 

Fig. 3 is a block diagram of a system architecture of 
a card management system in accordance with an embodiment 
25 of the present invention; 

Fig. 4 is a schematic diagram giving an example of an 
overall linked system including entities running a 
plurality of card management systems in accordance with 
embodiments of the present invention, for managing 
30 transactions for multiple product cards; 

Fig. 5 is an illustration of application of a 
management system in accordance with an embodiment of the 
present invention; 

Fig. 6 is a schematic diagram illustrating processing 
35 of a compound transaction in a management system in 

accordance with an embodiment of the present invention; 
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Fig. 7 is a schematic diagram illustrating a smart 
card reconstruction process utilising a management system 
in accordance with an embodiment of the present invention; 
Fig. 8 is a schematic diagram illustrating an 
5 application download to a smart card utilising a management 
system in accordance with the present invention, and 

Fig. 9 is a schematic diagram illustrating a process 
for deleting an application from a smart card utilising a 
management system in accordance with an embodiment of the 
10 present invention. 

Figure 1 shows the current environment for management 
of card products. 

The environment includes a card issuer 1. The card 
issuer is responsible for issuing and managing a card 2 
15 (perhaps by way of a separate card-manufacturing bureau) to 
a cardholder 3. The card issuer may be a bank or other 
financial institution that wishes to issue cardholders 
cards having a credit card product, for example. The card 
issuer would require details of the identity of the 
20 cardholder, address, credit rating, etc. 

The environment also includes a transaction acquirer 
4. The transaction acquirer is responsible for deploying 
and managing devices 5 (perhaps by way of a third party 
distributor) to a card accepter 6. The transaction 
25 acquirer may be a bank or other organisation that wishes to 
deploy devices to card accepters who support a credit card 
product, for example. The transaction acquirer would 
require details of the identity of the card accepter, 
address, bank account details, etc. 
30 Traditionally, dedicated computer systems are used to 

manage the card product in the current environment. These 
systems are subject to the problems discussed in the 
preamble of this specification. 

Referring to figure 2, a modified environment is shown 
35 which is facilitated by the card management system in a 

preferred embodiment of the present invention. In addition 
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to the card manager 1 (the renamed card issuer) and device 
manager A (renamed transaction acquirer), there is a 
further entity, product owner 7. The product owner 7 is 
responsible for management of aspects of the environment 
5 that relates to a particular product supported by the card 
2 and the device 5. The product owner is only responsible 
for the product. The product owner is not responsible for 
other aspects of the card and device environment that are 
not specifically product related, such as issuing and 

10 managing cards and deploying and managing devices. A 
product owner needs only information on a card, device, 
cardholder and card accepter that is required to operate 
the product. The product owner 7 will have relationships 
with card accepters and card holders who support the 

15 product. 

The product owner, card manager, and device manager 
functions may be carried out by one or more entities, which 
may- in turn perform one of more functions. In this way, 
many scenarios are supported. For example, one entity may 
20 only perform the product owner function, another entity may 
perform the card manager and product owner function, a 
third entity may perform all three functions, whilst a 
final entity may perform only the device management 
function. 

25 The architecture of the management system in 

accordance with an embodiment of the present invention is 
illustrated schematically in figure 3. The management 
system comprises a message management module 10, card 
management module 11, device management module 12, and 

30 product management module 13. 

The message management module which is arranged to 
receive message-data (e.g., from devices) and forward the 
message data onto the appropriate service management module 
11, 12, 13. Similarly, it can receive message data from 

35 the management module 11, 12, 13 and forward them out of 
the system or to other management modules. 
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Each of the management system modules includes 
functionality that enables management of cards (card 
management module 11), devices (device management module 
12) and products (product management module 13) . 
5 The system also comprises one or more business modules 

14. These modules encapsulate the functionality required 
to meet a particular business need of one or more entities 
participating in a card environment utilising a management 
system in accordance with the present invention. The 

10 business modules provide extensions and/or constraints to 
the management system in order to support specific business 
requirements. For example, they may support the technical 
implementation of the MULTOS card platform, support an 
interface to a legacy database system, support transaction 

15 processing specific to a particular product, or manage 
transactions received from a particular device. 

Each of the card 11, device 12 and product management 
13 modules (the service modules) include relational 
databases and processing means to provide the following: 

20 

Product Management Module 

1. Provide products for card holders (Card holder product 
to Product owner) and Card Acceptors (in the form of a Card 
Acceptor product to a Product Acceptor) . 
25 2. Establishment of products within Card Manager/Device 
Manager constraints. 

3. Process product transactions. 

4. management of relationships with suppliers, Card 
holders/Card acceptors and Card Managers/Device managers. 

30 5. Supports management of product life cycle (including 
product data and applications) and the management of 
supported device/card relationships per Product (including 
the relationships with Card Managers and Device Managers) . 
6. Manage card products and related information. 

35 7. Product specifications. Specifies card and device 
applications, compatible card and device platforms, 
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required memory of cards/devices, parameters and data 
requirements . 

8. Product relationships e.g. relationships between 
different products. 
5 9. Product parameters/configuration. 

10. Primary product certificates, cryptography. 

11. Card Manager and Device Manager information. Multiple 
card managers and device managers may support product. 

12. Links to or data from the card management module for 
10 card holders using the product. 

13. Device management links. Links to or data from the 
device management module for card acceptors supporting the 
product . 

14. Transaction data may be required to be mirrored for 
15 reconstruction . 

15. Card/device application. 

16. Application provision. Dynamic downloading of 
applications to cards. 

20 Device Management Module 

1. Establish and manage devices used by card acceptors. 

2. Establishment of devices at card acceptor locations. 

3. Deployment of products from product owners. 

4. Management of relationships with suppliers, card 
25 acceptors and product owners. 

5. Ordering of devices from vendors. 

6. Maintenance and management of device inventories and 
devices installed (including data & applications on 
devices) . 

30 7. Management of supported product relationships per 
device (including the relationships with the product 
owners) . 

8. Device specification data. To define device 
maintenance/management processes - provides details about 
35 capacity for applications, etc. 



WO 00/51070 27 PCT/AU00/00123 

9. Device parameters/configuration data required for 
device installation reconstruction processes. Defines 
device manager specific configuration of device data. 

10. Primary device certificates, keys - cryptography. 

11. Device product applications, links. Product 
applications may be managed by the transaction processor 
but for device reconstruction processes at least links are 
maintained. 

12. Card acceptor data e.g. conduct details, full title, 
demographic information, etc. 

13. Card acceptor/Device relationships. Multiple device 
may be linked to same card acceptor. 

14. Card acceptor establishment e.g. through manual data 
entry, electronic file import. 

15. Card acceptor communications. Statements, etc. 

16. Application distribution. Keep track and distribute 
applications to devices and card applications to be 
distributed to smart cards. 

17. Device utilisation provides device manager with tools 
to specify the data to be included on the device. 

18. Device update reconfiguration update and reconfigure 
device . 

19. General device/card acceptor management. Fees, 
management , reports . 

Card Management Module 

1. Issue and manage cards used by card holders. 

2. Issuing of cards to card holders (including re- 
issuing/reconstruction) 

3. Deployment of products from product owners. 

4. Management of relationships with Suppliers, Card 
holders and Product owners. 

5. Ordering of cards from vendors. 

6. Management of card stock and cards issued (including 
data and applications on card) 
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7. Management of supported product relationships per card 
(including the relationships with the product owner) . 

8. Card holder Data. All card holder related data is 
required to be captured and maintained by the card 

5 management module e.g. card holders name, contact details, 
identification references, demographic information, market 
research findings and diary notes. 

9. Card/card holder relationships (relationship links 
required for many to many relationships between cards and 

10 card holders. Multiple card holders may be linked to the 
same group (e.g. family cards) - multiple cards to same 
card holder (company, corporation cards) . 

10. Card specification data, card platform issued, memory 
capacity, types of memory, for capacity of applications. 

15 11. Card parameters/configuration data - for card 

production/updating/reconstruction processes. Specify how 
card memory space is used and data/applications downloaded 
onto card and defines general card issuer specific 
configuration of the card data (this does not include 

20 product specific data/applications. 
12. Personalisation data for card 

production/reconstruction processes specifies the card 
holder data provided on the card, which may be number of 
cardholder data. 
25 13. Primary card certificates/keys (cryptography) 

14. Card product applications/links - maintains links to 
product manager to enable reconstruction of card. 

15. Card holder establishment, through manual data entry, 
electronic file import, etc. 

30 16. Card holder communications e.g. event dates/time dates 
such as card issuance. 

17. Card production/issuance provides tools for card 
manager to specify data to be included on cards and provide 
for unique ID of card. 
35 18. Card updating/reconstruction - facility to update 

reconstruct specified card or range of cards - may require 
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the need for regular "reconciliations" with card in on-line 
environment* 

19. General card management. Card/card holder requirement 
(determining reports, etc) participants related 
5 requirements (fees payable, renewable) . 

The message management module enables the following 
functions: 

Message management Module 
10 1. Manages message and data flows for and between the 
service and business modules. 

2. Captures formatting, routing and logging of 
transactions/messages . 

3. Sending and receiving of transactions/messages within 
15 and between the connected management systems as well as 

external systems devices and cards. 

4. Cryptographic processing of data, including 
authentication . 

5. Logging of billable events and support for activity 
20 based and generic fees. 

6. Production of standard and ad hoc reports. 

7. Administration of systems, including installation, 
configurations, access control, monitoring, recovering and 
archiving. 

25 8. Compliance with generally accepted standards, 
performance and operational criteria, including 
localisation of implementation. 

9. Manage and route messages to/from interconnected 
systems, devices and cards. 
30 10. Manage communications to/from individuals and 
organisations (e.g. customer inquiries, letters) . 

11. Produce information representing fees. 

12. Perform system administration tasks (e.g. installing 
and uninstalling configuring, performance monitoring, 

35 logging, notifying users, detecting and analysing 
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anomalies, backing up and restoring, archiving and 
retrieving. 

13. Support appropriate access control, physical security 
and cryptographic processing (e.g. authentication, 

5 encryption) . 

14. Record and review the current and historical state of 
the system (e.g. for audit purposes) . 

15. Convert from transaction format to the internal 
transaction format of the service module or external 

10 system. 

16. Capturing transactions and writing them to a log sheet 
for reconciliation, auditing, etc. 

17. Transaction splitting. Some transactions received may 
be compound transactions (same transaction applies to 

15 multiple products or applications) and are required to be 
split into two or more atomic transactions - transactions 
must be routed as early in the transaction chain as 
possible to ensure highest data privacy possible. 

For a particular operator of the management system in 

20 accordance with the present invention, they may have one, 
two or all of the three management modules 11, 12, 13, 
depending upon their function as an entity in the 
environment. Referring to figure 4, for example, entity 
one is an organisation that wishes to provide and run 

25 certain products. All they require of the system is the 
foundation module and the product management module, as 
well as any business modules that may be needed in order to 
support particular business functionality. Entity two is a 
card and device manager, whilst entity three is a card 

30 manager, device manager and also a product owner. 

Each of the management systems of entity one, entity 
two and entity three may be connected to support various 
products. For example, a product owner may establish a 
commercial relationship with entity one and/or entity two 

35 as the card manager and/or device manager for their 
particular product. 
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In operation, a cardholder 1 who requires an available 
product may seek the product from the product owner. The 
product may be provided as a software application 
downloaded via a device 5, The cardholder could in fact 
5 interact directly with the device to request the product, 
provide any details that may be required (if they cannot 
already be provided from the details that the card manager 
has on the cardholder) . The product can then be entered on 
the card holders card. 

10 Fig. 5 is an illustration of an example configuration 

of the use of management systems in accordance with the 
present invention. Two participants are illustrated. 
Participant "A" is a bank or other financial institution 
that operates a credit card product. They run a management 

15 system in accordance with the present invention, including 
message management module 20, card management module 21, 
device management module 22 and product management module 
23. Business management module a 24 and business 
management module b 25 are also provided. Participant A 

20 not only manages the credit card product using product 

management module 23, but also manages devices 26 and cards 
27, utilising device management module 22 and card 
management module 21, respectively. 

Participant "B" is an airline which owns a loyalty 

25 product. They have a system in accordance with the present 
invention comprising a message management module 28, a 
product management module 29, business management module c 
30 and a loyalty system application 31. The loyalty system 
application 31 is an application designed specifically for 

30 participant B, for processing its loyalty system 
transactions . 

Card holder 32 possesses a card 27 which supports both 
the credit card product of participant A and the loyalty 
product of participant B. 
35 Card holder 32 purchases goods from card acceptor 33. 

In order to pay for the goods the cardholder uses the 
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credit card product on the card 27 via device 26. Message 
data 34 generated by the device 26 is transferred directly 
to the message management module 20 participant A. Message 
management module 20 routes the message data to the device 
5 management module 22. The device management module 

determines that message data relates to a transaction which 
is associated with their credit card product and also with 
the loyalty product of participant B. The device 
management module 22 operates to break down the transaction 

10 data into message data for the participant B and also 
message data for the product management module 23 of 
participant A. Message data for the product management 
module 23 is routed via the message management means 20 to 
the product management module 23. The credit transaction 

15 is an "on us" transaction and the product management module 
23 determines that the participant A is also the card 
manager 21. Appropriate transaction information may be 
provided to the card management module 21 via the message 
management module 20 and also to an external credit card 

20 processing system 34 after having been converted by 

business module a 24 into an appropriate (different) form 
required for the credit card processing external system 34. 
The system 34 may be a legacy system which was already in 
place at participant A before installation of the 

25 management system of the present invention. 

The message data intended for the participant B is 
first of all routed by business management module b 25, for 
appropriate cryptographic conversion. Participant B 
requires that this cryptographic processing be carried out 

30 for security purposes. After processing by the business 
management module b 25, the encrypted message data is 
transmitted via the message management module 20 to- the 
message management module 28 of participant B. Message 
management module 28 passes on the message data to product 

35 management module 29. The product management module 2 9 

calculates loyalty points, for example. In this particular 
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case, participant B has a separate loyalty product system 
31 that needs to be updated with the loyalty points. 
Further message data generated by the product management 
module 29 and including the loyalty point information is 
5 converted via business management module c 30 to an 
appropriate format for the loyalty point system 31 and 
passed to the loyalty point system 31 via the message 
management module 28. 

Another example of the utility of the management 
10 system of the present invention is in the handling of 
compound transactions. 

A compound transaction is a single transaction which 
applies to multiple applications managed by the same or 
different processing systems /management systems of the 
15 present invention. For instance, a credit product 

transaction with an attached loyalty product may generate 
one transaction between smart card and device; however, the 
atomic transactions for the credit product and the loyalty 
product may be routed to different systems. Compound 
20 transactions occur each time multiple applications generate 
a compound transaction during the interaction between smart 
card and devices. 

Figure 6 illustrates the transaction flow for a 
compound transaction. The steps involved are described in 
25 detail below. 

1. During an interaction between smart card 4 0 and device 
41, multiple applications generate a compound transaction. 

2. Periodically the device dials into the Device 
Management 42 to upload all transactions, which are logged 

30 by the Message Management module 4 3 of the Device 
Management 42. 

3. The Device Management 42 applies pre-defined rules to 
the logged transactions. A compound transaction rule 
generates multiple atomic transactions destined for 

35 multiple management systems in accordance with the present 
invention or legacy systems. 
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4. The Device Management 42 transmits the atomic 
transactions to one or more Product Management modules, 44 , 
45 and/or to one or more legacy systems 46, for further 
processing. 

5 5. The Device Management may optionally transmit an 
advice to one or more Card Management systems to advise 
altered smart card data or applications. 
Other possibilities are: 

1. Multiple applications operating concurrently may 

10 generate an atomic transaction each, such that no compound 
transactions occur. 

2. A compound transaction may be divided into its atomic 
transactions in the device prior to a periodic batch 
transmission to the Device Management. 

15 The process of recreating smart cards may become 

necessary when cardholders advise the card issuer that the 
smart cards are lost or stolen. The recreation of the 
smart card involves blocking the lost/stolen card, 
accumulating the applications and data from the Card 

20 Management system, and personalising a new smart card. 

The Card Management may only recreate the smart card' s 
applications and data for which the Card Management has 
received explicit permission from the cardholder. The 
cardholder is responsible for recreating private data. For 

25 instance, cryptographic keys may only be obtained by the 
cardholder or by the Card Management with explicit 
permission from the cardholder, possible through a request 
to the Product Management module which may request the 
cardholder keys for an application from the CA. 

30 Figures 7 illustrates the transaction flow for the 

recreation of a smart card. The steps involved are 
described in detail below. 

The steps of the transaction flow may be described as 
follows : 
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1. The cardholder 50 requests a smart card recreation 
from the card issuer 51, and provides card issuer 51 with 
desired permission for the reconstruction process . 

2. The card issuer instructs the Card Management module 
5 52 to block the previous card and schedule the 

reconstruction process, and requests a smart card 
reconstruction . 

3. The Card Management 52 generates a new card number, 
assimilates the cardholder data, the card applications 

10 references and requests the applications and possibly the 
permissive card data (Should the card data not reside 
within the Card Management module) from one or more Product 
Management modules 53 and/or one or more legacy systems 54 
referred to in the card application references. 

15 4. The Product Management modules (s) 53 and/or legacy 
system (s) 54 review the permissions, may request the 
appropriate data from other sources, e.g. CA, update the 
appropriate databases with the new card number and transmit 
the applications and possibly the card data to the Card 

20 Management module 52 . 

5. The Card Management module 52 generates a 
personalisation file with all the assimilated applications 
and data. The personalisation . file may be processed in the 
form of a report by an independent card personalisation 

25 machine 55 and the card 56 submitted to the cardholder 50. 
Variations : 

1. The card Management may request a smart card or a 
range of smart cards to be reconstructed, e.g. the expiry 
date is printed on the card face. 

30 One of the major advantages of the management system 

in accordance with the present invention is that it enables 
dynamic loading and unloading of product applications from 
smart cards and/or devices after issuance of the smart card 
or installation of the device. 

35 The dynamic application load transfers an application 

to a smart card or device, to ensure that new applications 
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may be loaded onto smart cards after the cards have been 
issued, and loaded onto the devices after they have been 
installed. The application load transaction occurs upon 
request, the request may be issued by the management system 
modules or by the cardholder or card acceptor. 

Figure 8 illustrates one of the possible transaction 
flows for an application load transaction to smart cards. 
The steps involved in this variation are described in 
detail below. 

The step of the transaction flow to facilitate 
application loading onto smart cards may be described as 
follows : 

1. During the interaction between smart card 60 and 
device 61, the device offers the smart card 60 an 
application that is not resident on the smart card 60. 

(a) The smart card 60 may verify that the application 
may legally reside on the card manager's card (e.g. 
ascertaining that an agreement is in place between card 
manager and device manager for this application) . 

2. The cardholder agrees to load the application onto the 
smart card 60, the smart card 60 requests the device 61 to 
provide the application for the smart card 60 to load into 
its memory. 

3. The device dials into the Device Management 62 of the 
management system of the present invention. 

4. The Device Management 62 sends an application request 
to the Product Management 63. 

(a) Should the smart card 60 and device 61 not be 
able to ascertain the legality of the application on the 
smart card 60, the verification may be required between 
Device Management 62 and Card Management 64, prior to the 
application request being submitted to the Product 
Management 63. Also, if the application has a value 
associated with the application, the Device Management 62 
may ascertain that the smart card 60 has not been blocked. 
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5. The Product Management 63 provides the requested 
application to the Device Management " 62 . 

6. The Device Management 62 provides the requested 
application to the device 61. 

5 7. The device 61 discontinues the on-line link to the 
Device Management 62 and provides the smart card 60 with 
the requested application. 

8. The smart card 60 installs the application in its 
memory. 

10 9. The smart card 60 may send an advice of the successful 
loading to the device 61 for batch upload to the Device 
Management 62 for distribution to the requesting 
participant. This advice may be necessary for mission 
critical application, whilst other products or Card 

15 Management 64 may not require the advice. The Device 
Management 62 may transmit the advice to 

• Card Management 64 

• Product Management 63 

• both 

20 The Dynamic Application Load for devices may be facilitated 
in a similar manner with the instruction for the load 
originating either from the device, the Device Management 
module or the Product Management module. 

Note that the device management 62, product management 

25 63 and card management 64 may belong to the same entity or 
separate entities. 

Variations 

Other possibilities for application loads to smart 
30 cards are: 

1. The cardholder requests by phone that the application 
be loaded onto the smart card, e.g. the next time the smart 
card is on-line for another transaction. The Product 
Management will schedule the load and request the Device 
35 Management to provide the device with the application upon 
request, e.g. when the smart card is on-line. 
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2. The Product Management arranges an agreement with the 
Card Management to provide all the smart cards managed by 
the Card Management with an application- Either the Card 
Management or the Product Management instructs the Device 

5 Management to: 

(a) provide all the devices managed by the Device 
Management with the application upon request, e.g. when the 
smart cards are next on-line; 

(b) provide all the devices managed by the Device 

10 Management with the application the next time the devices 
are on-line, such that the application loading may be 
facilitated off-line when the smart cards interact with the 
devices. 

3. The Card Management instructs the Device Management to 
15 load applications onto a range of smart cards either: 

(a) the next time the smart cards are on-line for a 
transaction; 

(b) by pre-loading the application onto devices for 
off-line application loading. 

20 Other possibilities for application loads to devices are: 

1. The device requests on-line that an application be 
loaded, e.g. to process a transaction with a smart card 
which holds an unknown application. The Device Management 
requests the application from one or more Product 

25 Management modules. The application is loaded onto the 
device in a similar fashion to the smart card application 
load. Once the application is installed in the device, the 
transaction with the smart card may proceed. 

2. The Device Management requests the device applications 
30 from the Product Management module (s) and transfers the 

applications to a range/all devices for installation during 
the next interaction with the devices. 

3. The Product Management requests the Device Management 
to provide the devices with applications during the next 

35 interaction with the devices. 
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The dynamic application unload deletes an application 
from a smart card 70n or device 71 , to ensure that 
applications may be unloaded from smart cards after the 
cards have been issued, and unloaded from the devices after 

5 they have been installed- The application unload 
transaction may occur automatically (e.g. single use 
coupons) or upon request, the request may be issued by the 
modules of the management system of the present invention 
or by the cardholder or card acceptor. 

10 Figure 9 illustrates the transaction flow for an 

unload transaction. The steps involved are described in 
detail below. 

The steps of the transaction flow to facilitate 
application unloading from smart cards may be described as 

15 follows: 

1. The Card Management 72 may request the Device 
Management 73 to delete an application from a range of 
smart cards managed by the Card Management 73, 

(a) the next time the device 71 in on-line for a 
20 transaction with one of the smart cards 70 within the 

range; 

(b) broadcast the request to the devices 71 the next 
time the devices 71 are on-line for an interaction with the 
Device Management 73 such that the unload request may be 

25 communicated to the smart card 70 off-line during a 

transaction interaction (this mode may be necessary if the 
Card Management 71 discontinues the support of the 
application or a cardholder abuses the application) . 

2. During the interaction between smart card 70 and 
30 devices 71. 

(a) and the device has to dial-in to the Device 
Management 73 to complete the transaction, the Device 
Management 73 may request the device 71 to communicate the 
unload request to the smart card 70 as part of the response 
35 to the device 71. The device 71 discontinues the 

communication with the Device Management 73, completes the 
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transaction, and communicates the unload request to the 
smart card 70. 

(b) communicates the broadcasted unload request to 
the smart card 70. 
5 3. The smart card 70 deletes the application from its 
memory, with an optional advice to the device 71 tat the 
application ahs been deleted. The advice may be uploaded 
to the Device Management 73 during the next interaction, 
which may be transmitted to the Card Management 72 and the 

10 Product 73 Management modules. 

The Dynamic Application Unload for devices may be 
facilitated in a similar manner with the instruction for 
the load originating either from the device, the Device 
Management module or the Product Management module. 

15 Other possibilities for application unloads to smart 

cards and/or devices are: 

1. The Product Management may request the Device 
Management to unload an application from all smart cards 
and/or all devices, e.g. a discontinued application. 
20 2. The smart card may delete the application from its 
memory after a single use of the application, e.g. single 
use coupons. 

3. The device may request the smart card to delete the 
application from its memory after a single use of the 

25 application, e.g. single use coupons. 

4. The Device Management may request the device that an 
application that is no longer supported by the Device 
Management be deleted from the device's memory. 

Implementation of a management system in accordance 
30 with the present invention can enable methods of operating 
and making available products that are not presently 
practical. 

For example, card managers and device managers 
operating the system may publish a set of xx standards" for 
35 compliance with their systems. Product owners complying 

with those standards could then offer products for use with 
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the cards and devices managed by the card manager and 
device manager. There would be no need for any complex 
negotiations to establish the parameters of the 
relationship between the product owner, device manager and 
5 card manager. The product owner would merely have to 

arrange his product to comply with the standards and then 
make the product available to the card manager and device 
manager, who would in turn make the product available to 
the card holder. An already fully compliant product is 

10 offered for use with the systems. 

It will be appreciated by persons skilled in the art 
that numerous variations and/or modifications may be made 
to the invention as shown in the specific embodiments 
without departing from the spirit or scope of the invention 

15 as broadly described. The present embodiments are, 

therefore, to be considered in all respects as illustrative 
and not restrictive. 
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THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS: 

1. A card, device and product management system, 
including a card management means which enables a card 

5 manager participant to perform a card management role 

alone, without managing products associated with a card and 
without managing devices; 

a device management means which enables a device 
manager participant to perform a device management role 
10 alone, without managing products associated with the card 
and without managing cards; and 

a product management means, which enables a product 
owner participant to perform a product management role 
alone, without managing cards and without managing devices, 
15 whereby all three roles can be performed by separate 
entities. 

2. A system in accordance with claim 1, further 
comprising a message management means arranged to manage 
the routing of message data between cards, devices and a 

20 card, device and product management system. 

3. A system in accordance with claim 2, wherein the 
message management means is also arranged to act as a 
communication's interface routing message data between the 
card management means, device management means and product 

25 management means. 

4. A system in accordance with claim 2 or claim 3, 
the message management means also being arranged to manage 
the routing of message data to external systems. 

5. A system in accordance with any one of claims 2 

30 to 4, wherein each one of the card management means, device 
management means and product management means is provided 
with an associated message management means. 

6. A system in accordance with any one of the 
preceding claims, wherein the system is arranged so that 

35 the product management means is arranged to facilitate the 
product owner participant to directly affect control of a 
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product associated with a card or device, without 
intervention of any of the other participants. 

7. A system in accordance with claim 6, wherein the 
control of the product involves loading data to the 
product . 

8. A system in accordance with claim 6 or claim 7, 
wherein the control involves the product management means 
receiving data from the product via the system. 

9. A system in accordance with claim 8, wherein the 
data is transaction data. 

10. A system in accordance with any one of claims 6 
to 9, wherein the control involves the product management 
means downloading product applications directly to a card 
or device. 

11. A system in accordance with any one of claims 6 
to 10, wherein the system is arranged so that data 
associated with the product and provided to the product 
management means or to the card or device from the product 
management means may be routed via the message management 
means of other entities participating in the system. 

12. A system in accordance with any one of the 
preceding claims, wherein the card management means is 
arranged to store product owner identification data, 
identifying product owner participants responsible for 
managing products associated with cards managed by the card 
manager participant. 

13. A system in accordance with any one of the 
preceding claims, wherein the device management means is 
arranged to store product owner identification data, 
identifying product owner participants responsible for 
managing products associated with devices managed by the 
device manager participant, and card accepter 
identification data, identifying card accepters using 
devices managed by the device manager participant. 

14. A system in accordance with any one of the 
preceding claims, wherein the product management means is 
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arranged to store card manager identification data 
identifying card managers managing cards supporting 
products managed by the product owner participant. 

15. A product management system, comprising a product 
5 management means which enables a product owner participant 

to perform a product management role alone, without 
managing cards and without managing devices, wherein the 
system is arranged to facilitate the product owner 
participant to directly affect control of a product 
10 associated with a card or device. 

16. A system in accordance with claim 15, wherein the 
control of the product involves loading data to the 
product. 

17. A system in accordance with claim 15 or claim 16, 
15 wherein the control involves the product management means 

receiving data from the product. 

18. A system in accordance with claim 17, wherein the 
data is transaction data. 

19. A system in accordance with any one of claims 15, 
20 16 or 17, wherein the control involves the product 

management means downloading product applications to a card 
or device. 

20. A system in accordance with any one of claims 15 
to 20, wherein the product management means is arranged to 

25 store card manager identification data identifying card 

managers managing cards supporting products managed by the 
product owner participant. 

21. A card management system, including a card 
management means which enables a card manager participant 

30 to perform a card management role alone, without managing 
products associated with a card and without managing 
devices . 

22. A card management system in accordance with claim 
19, wherein the card management means is arranged to store 

35 product owner identification data, identifying product 
owner participants responsible for managing products 
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associated with cards managed by the card manager 
participant . 

23. A device management system, including a device 
management means which enables a device manager participant 
to perform a device management role alone, without managing 
products associated with a card and without managing cards. 

24. A device management system in accordance with 
claim 21, wherein the device management means is arranged 
to store product owner identification data, identifying 
product owner participants responsible for managing 
products associated with devices managed by the device 
manager participant, and card accepter identification data, 
identifying card accepters using devices managed by the 
device manager participant. 

25. A card, device and product management system, 
including a plurality of service processing means, each 
service processing means enabling a participant to the 
system to carry out at least one of card, device and 
product management, and a message management means provided 
to each participant in the system and arranged to act as a 
communications interface routing message data between each 
of the service processing means and between cards and 
devices, to enable a network of service processing means 
and a plurality of participants to interface to carry out 
card, device and product management. 

26. A card, device and product management system 
including a network comprising a plurality of nodes, each 
node comprising a service processing means enabling a 
system participant to carry out at least one of card, 
device and product management, and a message management 
means arranged to act as a communications interface routing 
message data between the service processing means of each 
node and between cards and devices. 

27. A system in accordance with claim 26, wherein the 
service processing means includes a device management means 
which enables a device manager participant to perform a 



WO 00/51070 - 46 - PCT/AU00/00123 

device management role alone, without managing products 
associated with a card and without managing cards. 

28. A system in accordance with claim 26 or claim 27, 
the service processing means including a card management 

5 means which enables a card manager participant to perform a 
card management role alone, without managing products 
associated with a card and without managing devices. 

29. A system in accordance with any one of claims 26, 
27 or 28, wherein the service processing means includes a 

10 product management means which enables a product owner 
participant to perform a product management role alone, 
without managing cards and without managing devices. 

30. A method of managing cards, devices and products, 
comprising the steps of defining a tripartite environment 

15 for card management, the card management tripartite 
environment comprising; 

a card manager participant responsible for managing 
non-product specific card operations; 

a device manager participant responsible for managing 
20 devices for accepting cards and for carrying out product 
transactions; and 

a product manager participants, responsible for the 
management of product-related aspects of the card 
environment, wherein the device manager participant, card 
25 management participant and product manager participant may 
be separate entities. 

31. A method in accordance with claim 30, comprising 
the further step of providing a computer system including 
modules enabling each of the card manager participant, 

30 device manager participant and product manager participant 
roles to be carried out separately from each other. 

32. A method in accordance with claim 30 or claim 31, 
comprising the step of enabling the system to facilitate 
the product manager participant to have direct access to a 

35 product in order to directly affect control of a product 
associated with a card or device. 
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33. A method in accordance with claim 30, comprising 
the step of enabling the product owner participant to load 
data onto the product. 

34. A method in accordance with claim 32 or claim 33, 
comprising the step of enabling the product owner 
participant to receive data from the product. 

35. A method in accordance with claim 34, wherein the 
data is transaction data. 

36. A method in accordance with any one of claims 32 
to 35, comprising the step of the product owner participant 
downloading a product application to a card or device. 

37. A method of managing products, comprising the 
steps of defining a product manager participant, 
responsible for the management of products alone, without 
managing cards and without managing devices, and providing 
the facility for the product manager participant to 
directly affect control of a product associated with a card 
or device. 

38. A method in accordance with claim 37, including 
the step of providing the facility to enable the product 
owner participant to load data to the product. 

39. A method in accordance with claim 37 or claim 38, 
including the step of providing the facility to enable the 
product manager participant to receive data from the 
product on the card or device. 

40. A method in accordance with claim 39, wherein the 
data is transaction data. 

41. A method in accordance with any one of claims 37 
to 40, including the step of providing the facility to 
enable the product owner participant to download product 
applications to a card or device. 

42. A method of managing cards, comprising the steps 
of defining a card manager participant whose role is to 
perform management of cards alone, without managing 
products associated with a card and without managing 
devices . 
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43. A method of managing devices, comprising the 
steps of defining a device manager participant whose role 
is to perform management of devices alone, without managing 
products associated with a card and without managing cards. 

44. A generic system for the management of cards, 
devices and products, the system including a card 
management module, a device management module and a product 
management module, which can be used separately and 
networked with each other to enable different entities to 
carry out card management, device management and product 
management alone, and to network with other similar systems 
to facilitate card, device and product management. 

45. A system in accordance with claim 44, further 
comprising a message management module arranged to act as a 
communications interface to manage the routing of message 
data between cards, devices, products, card management 
modules, product management modules and device management 
modules and wherein each participant in the generic system 
utilises a message management module. 

46. A card, device and product arrangement, including 
a computing system having memory locations for receiving a 
plurality of product applications, and security means 
enabling selective access to the memory locations for a 
plurality of product owners, whereby the product owners may 
separately access and manage their products stored at the 
memory locations. 

47. A card, device and product arrangement in 
accordance with claim 4 6, wherein the memory locations are 
provided mounted on cards. 

48. A card, device and product arrangement in 
accordance with claim 47 or claim 48, wherein the memory 
locations are provided mounted on the devices. 

49. A card device and product arrangement in 
accordance with claim 46, 47 or 48, wherein the security 
means comprises tokens operating as keys to enable access 
to the memory locations. 
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50. h card, device and product arrangement in 
accordance with any one of claims 46 to 4 9, including a 
product management system in accordance with any one of 
claims 15 to 20 to enable management of product by a 

5 product owner. 

51. A card, device and product arrangement in 
accordance with any one of claims 46 to 49, including a 
card, device and product management system in accordance 
with any one of claims 1 to 15, to enable management of the 

10 arrangement. 
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